Re: [gt-user] SimpleCA and EPEL repo

[Daniel Powers]

Hi Mohan,

The issue here is that the EPEL repository contains myproxy packages that are 
not compatible with the Globus software you are trying to install and use. 
You'll need to make sure that you pull the myproxy packages from the Globus 
repository, as opposed to the EPEL repository, to get the right version of the 
myproxy software. One way to approach this is to install the 
yum-plugin-priorities package prior to using yum to install the Globus 
software. When you install the rpm file that configures the Globus repository, 
it will configure our repository with a priority field in the repo file. This 
field isn't used unless the yum-plugin-priorities package is installed, 
however. Once the yum-plugin-priorities package is installed, the Globus 
repository will have a higher priority than the EPEL repository, and the 
myproxy packages will be pulled from the Globus repository in preference to the 
EPEL repository. So, if you want to install the Globus software with EPEL 
enabled, make sure that you install the yum-plugin-priorities package first. 

-Regards

Dan Powers

 From: Mohan G mail2moha...@gmail.com
 Subject: [gt-user] SimpleCA and EPEL repo
 Date: February 26, 2015 at 8:18:00 PM CST
 To: gt-user@lists.globus.org

 Hi,
 I am install Globus Toolkit on Cent 7.0 using the qickstart tutorial.

 I installed EPEL (ver. 7.5) and Globus (ver. 6-14) repositories, then
 I executed yum install globus-gridftp globus-gram5 globus-gsi myproxy
 myproxy-server myproxy-admin. All the packages are installed properly
 but the simpleCA did not  generate the host certificate automatically.
 So when I executed the next command install -o myproxy -m 644
 /etc/grid-security/hostcert.pem
 /etc/grid-security/myproxy/hostcert.pem give error.

 But if I do not install EPEL and did the rest same, then simpleCA
 generates the host certificate automatically in /etc/grid-security.
 This is confusing me as the quickstart says that EPEL repository must
 be enabled for cent OS.

 Can someone clarify this.

 -Mohan G

Re: [gt-user] Sudden interrupt during a transfer

[Daniel Powers]

Hi Fabio,

Could you provide a bit more background on this transfer? Specifically, can you 
tell me what kind of systems (sender and recipient) are involved here - system 
using globus-url-copy, system with toolkit GridFTP, Globus Connect Server 
endpoint, Globus Connect Personal endpoint, etc.?

-Dan Powers

From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Fabio Moreira [souza.fab...@gmail.com]
Sent: Friday, October 16, 2015 9:16 AM
To: gt-user@lists.globus.org
Subject: [gt-user] Sudden interrupt during a transfer

Hi,

I would like a help with a weird behavior of a transfer. After 2 minutes the 
transfer was suddenly interrupted with the message below. I don't know if there 
is any influence but the average latency between the servers is 120 ms. I 
repeated the transfer many times and the behavior was always the same.

error: globus_xio: System error in recv: Connection reset by peer
globus_xio: A system call failed: Connection reset by peer

I've made the same transfer using scp and no problem happened.

Best Regards,

Fabio Souza

Re: [gt-user] Help installing on Fedora 21 64 bit

[Daniel Powers]

Hi Tony,

There was an issue with our Fedora repo that may have been causing the 
difficulties you encountered. This issue has since been corrected by the devs. 
Since the repository fix has been made, I have successfully installed the 
globus-resource-management-client, globus-resource-management-server, and 
globus-resource-management-sdk packages onto a Fedora 21 test instance. Can I 
get you to try the following on your Fedora 21 system:

1) yum remove \*globus\*
2) yum update
3) yum install yum-plugin-priorities
4) wget 
http://toolkit.globus.org/ftppub/gt6/installers/repo/globus-toolkit-repo-latest.noarch.rpm
5) yum install globus-toolkit-repo-latest.noarch.rpm
6) yum install globus-resource-management-client
7) yum install globus-resource-management-server
8) yum install globus-resource-management-sdk

Let me know if you continue to have problems installing these packages after 
attempting the above procedure.

-Regards

Dan Powers 


From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Tony Howard [tahow...@nc.rr.com]
Sent: Saturday, August 22, 2015 3:14 PM
To: gt-u...@globus.org
Subject: [gt-user] Help installing on Fedora 21 64 bit

Hi,

I'm trying to install globus using yum.  Most packages install properly,
but I get errors when In install the resource management portions:

# yum -y install globus-resource-management-client
globus-resource-management-server globus-resource-management-sdk
...
--> Running transaction check
...
---> Package globus-common.i686 0:15.30-1.fc21 will be installed
--> Finished Dependency Resolution
Error:  Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:

  1. You have an upgrade for globus-common which is missing some
 dependency that another package requires. Yum is trying to
 solve this by installing an older version of globus-common
of the
 different architecture. If you exclude the bad architecture
 yum will tell you what the root cause is (which package
 requires what). You can try redoing the upgrade with
 --exclude globus-common.otherarch ... this should give you
an error
 message showing the root cause of the problem.

  2. You have multiple architectures of globus-common installed, but
 yum can only see an upgrade for one of those architectures.
 If you don't want/need both architectures anymore then you
 can remove the one with the missing update and everything
 will work.

  3. You have duplicate versions of globus-common installed already.
 You can use "yum check" to get yum show these errors.

...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).

Protected multilib versions: globus-common-15.30-1.fc21.i686 !=
globus-common-15.31-1.fc21+gt6.x86_64
Error: Protected multilib versions:
globus-common-devel-15.30-1.fc21.i686 !=
globus-common-devel-15.31-1.fc21+gt6.x86_64

I think the resource management RPMs may be prereqing the 32 bit
versions of globus-common, which appear to conflict with the 64 bit
ones.  When I download the rpms manually, I get:

# rpm -i globus-resource-management-client-6.0-1.fc21+gt6.x86_64.rpm
error: Failed dependencies:
globus-core is needed by
globus-resource-management-client-6.0-1.fc21+gt6.x86_64
# yum -y install globus-core
Loaded plugins: langpacks
Package matching globus-common-devel-15.30-1.fc21.x86_64 already
installed. Checking for update.
Nothing to do
#

Any ideas how I can install it?

Tony

Re: [gt-user] Announcing GT 5.2.5 end-of-life

[Daniel Powers]

Hi Steven,

Unfortunately, the GSI-OpenSSH packages are not in the Debian 7 backports repo 
at this time. Regarding the larger question of the GT6 packages generally, we 
did basic installation tests for GridFTP, MyProxy and GRAM and were successful 
with those tests. However, as mentioned, the GSI-OpenSSH packages were not in 
the backports repo during our testing and are not there now. We're contacting 
the person who manages these packages in the backports repo to see what can be 
done to add these packages since your query shows there is a demand for them. 
Until that gets addressed, you may want to consider installing the GSI-OpenSSH 
packages from the Globus repo - if that fits your use case. If you are 
interested in installing packages from the Globus GT6 repo, the following URL 
should help you to get started

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

-Dan Powers


From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Clark, Steven M [cla...@purdue.edu]
Sent: Wednesday, June 08, 2016 12:43 PM
To: Stuart Martin; gt-user; GT developer
Subject: Re: [gt-user] Announcing GT 5.2.5 end-of-life


Has anybody been able to install GT6 on a Debian wheezy system?

We are using the Debian backports repo but are unable to locate packages for

gsissh and friends.


---
Steven Clark
Application Engineer for Scientific Computing

From: gt-user-boun...@lists.globus.org  on 
behalf of Stuart Martin 
Sent: Thursday, May 12, 2016 3:35 PM
To: gt-user; GT developer
Subject: Re: [gt-user] Announcing GT 5.2.5 end-of-life

Hi All,

I’m reviving this thread.  It has been a while, but we had to get our
ducks in a row for how the Debian 7 and 8 upgrade path from GT 5.2.5 to
GT 6 will be handled.  In short, we will use Debian backports and have
added GT 6 to it.  New instructions for upgrading to Debian backports or to
Globus’ GT6 repo are here:
http://toolkit.globus.org/toolkit/docs/5.2-EOL.html

I hope this thread (started in July 2015) has been enough of a notice
of our intentions, that at this time, we are officially setting GT 5.2.x
to EOL.

The docs and downloads web pages have been updated to show that all of the non 
gt6 versions are now unsupported.
http://toolkit.globus.org/toolkit/docs/
http://toolkit.globus.org/toolkit/downloads/

Let us know if you have any questions.

The Globus team

On Sep 1, 2015, at 2:49 PM, Stuart Martin 
> wrote:

Hi Tom,  Comments inline.

On Aug 5, 2015, at 12:50 PM, Tom Downes > 
wrote:

Hi Stuart:

Sorry for the delayed response as I was on vacation. A quick inspection of the 
repository structure for GT6 versus GT5 eliminates a number of my complaints.

http://toolkit.globus.org/ftppub/gt5/5.2/ (e.g. I believe stable points to 
5.2.2)
http://toolkit.globus.org/ftppub/gt6/stable/deb/

For example, GT5 had different directories for Debian 7 versus 8. You now do 
this correctly by combining all deb-based dists under a single directory 
structure. You haven't quite gotten all the way since the more Debian way for 
this:

deb http://toolkit.globus.org/ftppub/gt6/stable/deb wheezy contrib
deb http://toolkit.globus.org/ftppub/gt6/testing/deb wheezy contrib

would be

deb http://toolkit.globus.org/ftppub/gt6/deb wheezy contrib
deb http://toolkit.globus.org/ftppub/gt6/deb wheezy testing

But this is a major improvement to the old directory structure. So kudos!

Thanks!

Comment 1: when you're managing N machines, it's much easier to know the 
sources.list entries and the signing key. Automated provisioning software 
(Foreman + preseed, for example) tend to be unfriendly toward unsigned 
packages. Not impossible, but it's much easier when the documentation just 
tells you the right path and points you to the key and you don't have to export 
it manually from the GPG file. I can see why a .deb is easier for Joe Sixpack 
walking up with one computer, but it's not easier for me.

This is mostly a documentation issue. We can pubish a directory of the repo 
configuration files and gpg key and include a link to that from the 
documentation in addition to the repo packages.  I created an issue for this.  
We’ll add this to our todo’s.

https://globus.atlassian.net/browse/GT-626

Comment 2: Do you intend for the stable repositories to contain the past 
history of releases even when they have been superseded? I hope so as this 
facilitates version pinning without being accidentally left behind.

We keep older versions in the repository.  So, you can specify an older version 
in case you need to back out from an update that goes bad, or stay pinned to a 
specific version if need be.

Comment 3: What is the closest repository to "proposed" in Debian-speak? i.e. a 
release that is going into the wild that, should no bug reports be filed, will 
be moved 

Re: [gt-user] sharing control

[Daniel Powers]

Hi Antoine,

>I did not find anything about these files. What is the format of these files? 
>Can local users control their share with these files?

The files in the sharing state directory describe the shares that exist on the 
endpoint. These files are autogenerated when shares are created and are not 
meant to be enduser created or modified. It is not possible for users to create 
a share simply by attempting to create one of the sharing state files.

>If I install GridFTP server in my lab without Globus Online subscription, is 
>it possible for a local user to :
>- control their own shares
>- grant access to $HOME/dir_A to a non local user named user_A
>- grant access to $HOME/dir_B to a non local user named user_B

Shares can only be created and used on Managed Endpoints, which are a type of 
endpoint covered under a Globus Subscription. If your endpoint is not managed, 
then it cannot host shares and users will not be able to creates shares based 
on your endpoint.

You can read more about sharing here:

https://docs.globus.org/globus-connect-server-installation-guide/#sharing_section

You can read more about Globus Subscriptions here:

https://www.globus.org/subscriptions

-Dan Powers


From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Antoine Migeon [antoine.mig...@u-bourgogne.fr]
Sent: Wednesday, March 22, 2017 5:28 AM
To: gt-user@lists.globus.org
Subject: [gt-user] sharing control

Hello,

I don't understand some points about sharing.

The documentation say :

 -sharing-state-dir string
Full path to a directory that will contain files used by GridFTP to control 
sharing access for individual local accounts.  The default path is 
$HOME/.globus/sharing/. ..

I did not find anything about these files. What is the format of these files? 
Can local users control their share with these files?

If I install GridFTP server in my lab without Globus Online subscription, is it 
possible for a local user to :
- control their own shares
- grant access to $HOME/dir_A to a non local user named user_A
- grant access to $HOME/dir_B to a non local user named user_B


Regards,
Antoine


--
Antoine Migeon

Centre de Calcul et Messageries
Pôle des Systèmes d'Information et des Usages du Numérique
Université de Bourgogne

Re: [gt-user] force command to use DNS name instead of IP for remote commands.

[Daniel Powers]

Hi Greg,

It sounds like your GridFTP servers are reporting their private IP addresses as 
their data interfaces. You can control the data interface that GridFTP (and 
globus-url-copy) report like so:

GridFTP:

Set the 'data_interface' option in your gridftp.conf file to the value you want 
it to advertise. This option is documented in the GridFTP man page, which you 
can read here:

https://docs.globus.org/globus-connect-server-installation-guide/man/globus-gridftp-server/

A GridFTP server will report the value set for the 'data_interface' option as 
the host/IP that other nodes should connect to if they are attempting to 
transfer data to this GridFTP server.

globus-url-copy:

Set the 'GLOBUS_FTP_CLIENT_DATA_IP' env variable to the value you want it to 
report for its data interface, and then export it. This will only be relevant 
in transfers where you are transferring between globus-url-copy and GridFTP 
directly, and won't matter for transfers where you are merely using 
globus-url-copy to transfer data between 2 GridFTP servers.

-Dan Powers

From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of greg whynott [greg.whyn...@gmail.com]
Sent: Tuesday, April 18, 2017 2:13 PM
To: gt-user@lists.globus.org
Subject: [gt-user] force command to use DNS name instead of IP for remote 
commands.

Hello,

First post,  searched around for an answer but maybe I'm not using the proper 
lingo.   sorry in advance if this has been covered previously.



3 machines involved,  3rd is where commands are being issued from (tor-hm1)  it 
is local to tor-xfer.

tor-hm1 - local network - behind NAT
tor-xfer - local network - behind NAT
chn-xfer remote network - public IP

This command works as expected,  moving data from tor-xfer to chn-xfer,

[hpcdata1@tor-hm1 ~]$ globus-url-copy -vb -cd -p 2 
sshftp://hpcda...@tor-xfer.removed.com/var/tmp/outtest.gz
 
sshftp://hpcda...@chn-xfer.removed.com/var/tmp/outtest.gz

Attempting to move data in the other direction from chn to tor,  this command 
will fail:

[hpcdata1@chn-xfer ~] globus-url-copy -vb -cd -p 2 
sshftp://hpcda...@chn-xfer.removed.com/var/tmp/chn-300k.fl
 
sshftp://hpcda...@tor-xfer.removed.com/var/tmp/chn-300k.fl

tor-hm1,  and tor-xfer are RFC1918 numbered and behind a NAT firewall with 1 to 
1 mapping to an outside address on the firewall.   Any traffic hitting this 
outside IP will be forwarded to tor-xfer.  THis has been tested and confirmed 
to work,  there are no readability issues from the remote network for any ports.

chn-xfer has an interface on a rotatable public IP,  no NAT.

tor-hm1 and tor-xfer use internal DNS.The answers returned are not the same 
as what the internet name servers will return when asking for host lookups. 
think split dns.

What appears to be happening is when tor-hm1 contacts chn-xfer,   it asks it to 
 "connect to this IP and send this file",  the problem is it is telling 
chn-xfer to connect back to the RFC1918 IP address,  not the public one.  which 
of course it can't reach.  This was verified via packet trace,  chn-xfer 
attempts to connect to tor-xfer's internal IP.



My question:,  Is there a method to force the hostname to be passed over to the 
remote server instead of the IP, so the remote end does the lookup? If 
chn-xfer did its own lookup on the name,  it would get the 'proper' IP to use 
and things would likely be good again.



 While I could be wrong,  it would seem to be a better idea to have the local 
NS used instead of the requester doing this for them,  what is the thinking 
here?  Just curious really.

thanks for your time,
greg

Re: [gt-user] gsi-openssh not installed from toolkit source build

[Daniel Powers]

Hi Jeff,

I've reported this issue to our devs, so they're now aware of it. You can track 
the issue here:

https://github.com/globus/globus-toolkit/issues/107

While waiting for a fix upstream, you'll need to edit the Makefile as you 
discussed.

Thanks for reporting this issue.

-Dan Powers

From: Jefferson Porter [rjpor...@lbl.gov]
Sent: Monday, July 31, 2017 4:58 PM
To: Daniel Powers
Cc: gt-u...@globus.org
Subject: Re: [gt-user] gsi-openssh not installed from toolkit source build

Hi Dan,

Thanks for the quick response.  I was doing some more digging and found the 
problem.  It dies trying to run 'mkinstalldirs /var/empty', which comes from 
the line in the gsi_openssh/source/Makefile:

(umask 022 ; $(srcdir)/mkinstalldirs $(DESTDIR)$(PRIVSEP_PATH))

Where DESTIR is empty.   In the newer versions, the Makefile has:


PRIVSEP_PATH=/var/empty

while in the older version (the ones that succeed for me)


PRIVSEP_PATH=${prefix}/var/empty

I'm doing a non-root installation on SUSE Linux 12.2, which is why it fails to 
make /var/empty.  I don't know if this is a mistake in the newer Makefiles.in 
or it was changed for a reason.

I can just edit the Makefile, but can this be fixed upstream?

thanks,

Jeff


On Mon, Jul 31, 2017 at 2:21 PM, Daniel Powers 
<dpow...@uchicago.edu<mailto:dpow...@uchicago.edu>> wrote:
Hi Jeff,

I just did a clean build & install from source using the latest GT6 source 
package (6.0.1493989444), and I found that /usr/local/globus-6/sbin/gsisshd and 
/usr/local/globus-6/bin/gsissh* were installed as expected. Can you try again 
with the latest GT6 source package and see if this resolves your issue?

If the above doesn't resolve your issue, could you please let us know what 
distribution you're doing your build on?

-Dan Powers

From: gt-user 
[gt-user-boun...@mail001.cels.anl.gov<mailto:gt-user-boun...@mail001.cels.anl.gov>]
 on behalf of Jefferson Porter [rjpor...@lbl.gov<mailto:rjpor...@lbl.gov>]
Sent: Monday, July 31, 2017 2:36 PM
To: gt-u...@globus.org<mailto:gt-u...@globus.org>
Subject: [gt-user] gsi-openssh not installed from toolkit source build


Hi,

We build the toolkit from the source tarball but I have been having a problem 
with the installation of gsi-openssh.  The executables are built and can be 
found under gsi_openssh/source/.libs but, unlike the rest of the toolkit, they 
are not installed with 'make install'.

I have kept some older tarballs and reran some build tests.  The problem 
appears to have occurred with the change of gsi_openssh versions.  At least my 
install of globus 6.0.1453307864 (gsi_openssh version 5.7) works while globus 
6.0.1461852459 (gsi_openssh version 7.1)  and later versions I've tested do not 
install gsi_openssh.   I scanned the build.log files and didn't see a reason 
for the problem.

thanks,

Jeff

--
R. Jefferson Porter, PhD
NERSC & Nuclear Science Division
Lawrence Berkeley National Laboratory
510-502-7231<tel:(510)%20502-7231>



--
R. Jefferson Porter, PhD
NERSC & Nuclear Science Division
Lawrence Berkeley National Laboratory
510-502-7231

Re: [gt-user] gsi-openssh not installed from toolkit source build

[Daniel Powers]

Hi Jeff,

I just did a clean build & install from source using the latest GT6 source 
package (6.0.1493989444), and I found that /usr/local/globus-6/sbin/gsisshd and 
/usr/local/globus-6/bin/gsissh* were installed as expected. Can you try again 
with the latest GT6 source package and see if this resolves your issue?

If the above doesn't resolve your issue, could you please let us know what 
distribution you're doing your build on?

-Dan Powers

From: gt-user [gt-user-boun...@mail001.cels.anl.gov] on behalf of Jefferson 
Porter [rjpor...@lbl.gov]
Sent: Monday, July 31, 2017 2:36 PM
To: gt-u...@globus.org
Subject: [gt-user] gsi-openssh not installed from toolkit source build


Hi,

We build the toolkit from the source tarball but I have been having a problem 
with the installation of gsi-openssh.  The executables are built and can be 
found under gsi_openssh/source/.libs but, unlike the rest of the toolkit, they 
are not installed with 'make install'.

I have kept some older tarballs and reran some build tests.  The problem 
appears to have occurred with the change of gsi_openssh versions.  At least my 
install of globus 6.0.1453307864 (gsi_openssh version 5.7) works while globus 
6.0.1461852459 (gsi_openssh version 7.1)  and later versions I've tested do not 
install gsi_openssh.   I scanned the build.log files and didn't see a reason 
for the problem.

thanks,

Jeff

--
R. Jefferson Porter, PhD
NERSC & Nuclear Science Division
Lawrence Berkeley National Laboratory
510-502-7231