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 
> Subject: [gt-user] SimpleCA and EPEL repo
> Date: February 26, 2015 at 8:18:00 PM CST
> To: 
>
> 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] Determining which advisories to install

[Daniel Powers]

Hi Adam,

That's the thing, when you build and install from source you really are stuck 
with having to track all of that manually. The only way you can be sure you've 
got all the needed fixes is to look at your source release date, and then apply 
all the patches that come out afterward. Once you've patched your source 
directory, you can then build your binaries/libs/etc again and reinstall. 
That's the only way I know to be sure your source built components have all the 
fixes. At least, that's the best I can come up with.

-Dan


From: Adam Mercer [mer...@uwm.edu]
Sent: Friday, June 12, 2015 10:49 AM
To: Daniel Powers
Cc: gt-user@lists.globus.org
Subject: Re: [gt-user] Determining which advisories to install

On Fri, Jun 12, 2015 at 10:46 AM, Daniel Powers  wrote:

> Probably the simplest way to check to see which fixes you need to install 
> would be to look at the release date for the source tarball you used for your 
> build. You could then apply all the fixes that came out after that date to 
> your source directory, then rebuild and reinstall whatever components you've 
> been using.

I thought about that but didn't want to get into the position where I
was installing updates that I didn't have installed or missing updates
that I thought I wasn't using but in fact was.

Cheers

Adam

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] 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] Sudden interrupt during a transfer

[Daniel Powers]

Hi Fabio,

Were you running 'globus-url-copy' with the '-c' (continue on error) option? If 
not, then you should give that a shot and see if that resolves your issue. The 
'globus-url-copy' command (GUC) will, by default, terminate on nearly any sort 
of error condition. Oftentimes, this can lead to GUC terminating on an error 
that could have otherwise been recoverable if the '-c' option had been used 
with the command. The "Connection reset by peer" error is an example of just 
this sort of error, as this often (though not always) can result from network 
or server conditions that are of a temporary nature, and that don't have to 
cause a transfer to fail. Please give the '-c' option a try and see if that 
enables your transfers to work more smoothly.

-Dan


From: Fabio Moreira [souza.fab...@gmail.com]
Sent: Monday, October 19, 2015 6:42 AM
To: gt-user@lists.globus.org; Daniel Powers
Subject: Sudden interrupt during a transfer

Hi Daniel,

We are using globus-url-copy between two servers. Find more details below:

Sender:
Red Hat Enterprise Linux Server release 6.6 (Santiago)
globus-version: 6.0
globus-gridftp-server -version: globus_gridftp_server: 7.25 (1428435129-85)

Receiver:
CentOS release 6.7 (Final)
globus-version: 6.0
globus-gridftp-server -version: globus_gridftp_server: 8.7 (1440180907-85)

Let me know if you need more informartion

Best Regards,
Fabio Souza

Message: 2
Date: Fri, 16 Oct 2015 22:38:54 +
From: Daniel Powers mailto:dpow...@uchicago.edu>>
To: Fabio Moreira mailto:souza.fab...@gmail.com>>, 
"gt-user@lists.globus.org<mailto:gt-user@lists.globus.org>"
mailto:gt-user@lists.globus.org>>
Subject: Re: [gt-user] Sudden interrupt during a transfer
Message-ID:

<736dc8b8696b91488b1c78fab9ad204afa5...@xm-mbx-09-prod.ad.uchicago.edu<mailto:736dc8b8696b91488b1c78fab9ad204afa5...@xm-mbx-09-prod.ad.uchicago.edu>>

Content-Type: text/plain; charset="iso-8859-1"

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<mailto:gt-user-boun...@lists.globus.org> 
[gt-user-boun...@lists.globus.org<mailto:gt-user-boun...@lists.globus.org>] on 
behalf of Fabio Moreira [souza.fab...@gmail.com<mailto:souza.fab...@gmail.com>]
Sent: Friday, October 16, 2015 9:16 AM
To: gt-user@lists.globus.org<mailto: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
--
Fábio MS

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

[Daniel Powers]

Hi Fabio,

Do you administer one or both of the GridFTP servers in question here? If so, 
then we should take this into a support ticket so that we can run some tests to 
verify their functionality as a first step. If not, then you might want to 
contact the admins of these servers to let them know about your issue, and to 
ask them to take a look at what could be causing the issue.

-Dan

From: Fabio Moreira [souza.fab...@gmail.com]
Sent: Tuesday, October 20, 2015 11:24 AM
To: Daniel Powers
Cc: gt-user@lists.globus.org
Subject: Re: Sudden interrupt during a transfer

Hi Daniel,

I'm running globus-url-copy with '-c' option but the transfer is still in 
trouble. See the exit below

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


error: There was an error with 1 transfer.

Thanks in advance

2015-10-19 13:43 GMT-02:00 Daniel Powers 
mailto:dpow...@uchicago.edu>>:
Hi Fabio,

Were you running 'globus-url-copy' with the '-c' (continue on error) option? If 
not, then you should give that a shot and see if that resolves your issue. The 
'globus-url-copy' command (GUC) will, by default, terminate on nearly any sort 
of error condition. Oftentimes, this can lead to GUC terminating on an error 
that could have otherwise been recoverable if the '-c' option had been used 
with the command. The "Connection reset by peer" error is an example of just 
this sort of error, as this often (though not always) can result from network 
or server conditions that are of a temporary nature, and that don't have to 
cause a transfer to fail. Please give the '-c' option a try and see if that 
enables your transfers to work more smoothly.

-Dan


From: Fabio Moreira [souza.fab...@gmail.com<mailto:souza.fab...@gmail.com>]
Sent: Monday, October 19, 2015 6:42 AM
To: gt-user@lists.globus.org<mailto:gt-user@lists.globus.org>; Daniel Powers
Subject: Sudden interrupt during a transfer

Hi Daniel,

We are using globus-url-copy between two servers. Find more details below:

Sender:
Red Hat Enterprise Linux Server release 6.6 (Santiago)
globus-version: 6.0
globus-gridftp-server -version: globus_gridftp_server: 7.25 (1428435129-85)

Receiver:
CentOS release 6.7 (Final)
globus-version: 6.0
globus-gridftp-server -version: globus_gridftp_server: 8.7 (1440180907-85)

Let me know if you need more informartion

Best Regards,
Fabio Souza

Message: 2
Date: Fri, 16 Oct 2015 22:38:54 +
From: Daniel Powers mailto:dpow...@uchicago.edu>>
To: Fabio Moreira mailto:souza.fab...@gmail.com>>, 
"gt-user@lists.globus.org<mailto:gt-user@lists.globus.org>"
mailto:gt-user@lists.globus.org>>
Subject: Re: [gt-user] Sudden interrupt during a transfer
Message-ID:

<736dc8b8696b91488b1c78fab9ad204afa5...@xm-mbx-09-prod.ad.uchicago.edu<mailto:736dc8b8696b91488b1c78fab9ad204afa5...@xm-mbx-09-prod.ad.uchicago.edu>>

Content-Type: text/plain; charset="iso-8859-1"

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<mailto:gt-user-boun...@lists.globus.org> 
[gt-user-boun...@lists.globus.org<mailto:gt-user-boun...@lists.globus.org>] on 
behalf of Fabio Moreira [souza.fab...@gmail.com<mailto:souza.fab...@gmail.com>]
Sent: Friday, October 16, 2015 9:16 AM
To: gt-user@lists.globus.org<mailto: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
--
Fábio MS



--
Fábio MS

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 
mailto:smar...@mcs.anl.gov>> wrote:

Hi Tom,  Comments inline.

On Aug 5, 2015, at 12:50 PM, Tom Downes mailto:dow...@uwm.edu>> 
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 unchanged into stable.

We have “Stable”, “Unstable” and “Testing” repos for each GT release versio

Re: [gt-user] gridftp issue

[Daniel Powers]

Hi Suchandra,

I don't have any experience with 'gfal-ls', but I can tell you that directory 
listing operations with GridFTP make use of the GridFTP control channel. By 
default, the GridFTP control channel uses TCP port 2811. Below is a link to our 
GCS firewall doc, which may be of use to you:

https://docs.globus.org/resource-provider-guide/#open-tcp-ports_section

If you're just using GridFTP outside of a GCS install / Globus endpoint, then 
not all of the ports specified in that doc will be relevant to you.

I hope the above is useful to you.

-Dan

From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Suchandra Thapa [ssth...@uchicago.edu]
Sent: Wednesday, July 20, 2016 12:23 PM
To: gt-user@lists.globus.org
Subject: [gt-user] gridftp issue

Hi,

I'm seeing an odd issue with gridftp that seems to be related to how gridftp 
uses ports.  I have a gridftp server running in a LXC container.  If I run 
gfal-ls on the container, I can get a directory listing.  However  gfal-ls 
hangs when run on the host running the container or another machine in the same 
data center.  The issue is probably a firewall or router blocking something but 
I'm having trouble figuring out what's been blocked.  What is the sequence for 
communications and ports being used when a gfal-ls is run against a gridftp 
server?  If it matters, GLOBUS_TCP_PORT_RANGE is set to 2,25000 .

Thanks,
Suchandra

Suchandra Thapa
sth...@ci.uchicago.edu
Computation Institute
Searle Chemistry Laboratory #201A
5735 South Ellis Avenue
Chicago, IL 60637

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] Updated source installer containing recent advisories

[Daniel Powers]

Hi Adam,

>Are there plans to update this source installer to contain these recent 
>advisories soon?

Our devs have weighed in on this, and they expect a new release of the 
installer package that addresses the issues you bring up to be available in a 
few weeks. We appreciate your patience in the interim.

>Is there a release branch that I can track to get these updates without 
>waiting for a new source installer to be created?

I'm sorry, but we don't have these updates available to users at this time.

-Dan Powers

From: gt-user-boun...@lists.globus.org [gt-user-boun...@lists.globus.org] on 
behalf of Adam Mercer [mer...@uwm.edu]
Sent: Tuesday, April 04, 2017 5:34 PM
To: gt-user@lists.globus.org
Subject: [gt-user] Updated source installer containing recent advisories

Hi

I maintain a packaging of the Globus Toolkit for macOS users within
the LIGO Collaboration, for this I take the latest source installer
from:

http://toolkit.globus.org/ftppub/gt6/installers/src/

which at the time of writing is globus_toolkit-6.0.1478289945.tar.gz,
compile using various options and package, along with other scripts
and packages into .pkg installer. according to the advisories page:

http://toolkit.globus.org/toolkit/advisories.html

There have been several updates since the last source installer was
created that sound important. I understand that I can download these
updates separately and install them but a much clear option is to
rebuild using an updated source installer.

Are there plans to update this source installer to contain these
recent advisories soon?

I believe that development is now done on GitHub at:

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

Is there a release branch that I can track to get these updates
without waiting for a new source installer to be created?

Cheers

Adam

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

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



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