[gin-data] Update Ftp transfers

[Raj Kettimuthu]

I guess the authentication errors in our tests (atleast for the transfers
between teragrid and hathi) was because the hathi's CA is not installed in the
trusted CA's directory on either on the other end of the transfer or at
the client's site.

After installing hathi's CA on my laptop, i was able to run transfers
between my laptop and hathi and also between ariane.doc.ic.ac.uk:55101,
hathi and grid-compute.leeds.ac.uk, hathi.

I noticed that some of the GIN GridFTP resources (including hathi) have a
directory in the url (eg: gsiftp://hathi.hep.lu.se:2811/public). I assume,
GIN users can only read from/write to only that location. For testing,
usually we do transfers from /dev/zero to /dev/null. But we can not do
this here. From some sites that have listed just the host:port, we are
not able to read from /dev/zero. For those sites, we are not sure where
(the path in the filesystem) to write the files to / read the files from.
We tried to write a file /tmp and read that file back. It succeeded in
some cases. We need to figure out a way to resolve this. Listing the
path(s), that the Gin users have access to, for each resource would be
good. Allowing Gin users to write to /dev/null would also be good.

Comments?

Raj


On Thu, 24 Aug 2006, Oxana Smirnova wrote:

> Hi,
>
> Gregor von Laszewski пишет:
>
> > As explained in my previous mail the reason for the failures were
> > related to authentication. I would therefore conclude that something
> > went wrong during the process of getting into the VO (hategan and
> > kettimuthu). Hence, I do suggest that the process of getting into the VO
> > be reevaluated by someone outside of our group just to make sure that
> > there is no bug in the process.
>
> I am not so sure this is the correct diagnostics: at least our server
> logs show the testers are properly authenticated
>
> > Do you have some documentation on how this system is configured. I was
> > under the impression that if I know the gridftp server and the address I
> > should just be able to start communication with it. That is essentially
> > what we tested on TG where it seems to work.
>
> Ours is not a Globus GridFTP server, and in this particular case it
> looks like some *old* Globus bug #1315 is acting up - Aleksandr (who
> reported the bug) may have more on it.
>
> > I assume once the VO accounting issues are solved I am almost certain we
> > can just replicate the experiment. Is there any volunteer that has these
> > accounts already?
>
> I am in GIN VO, and I am sure I have no *accounts* on any of those
> systems; yet here are my quick tests (pushing a 1MB file from my
> notebook all around the place):
>
> - Imperial College (EGEE) : success
> - Imperial College (London e-Science): failure because they didn't
> update IGTF certs for half a year or so
> - UC San Diego (OSG) : success
> - U of Chicago (Teragrid): failure, unable to connect at all
> - Leeds, Oxford, Manchester, RAL (NGS): failure, permission denied,
> connection closed
> - Lund (NorduGrid/ARC): success
>
> And that's it, I see no other addresses to try in GIN Wiki. Basically, I
> got only one (1) authentication error, and that was because folks at IC
> did not update their security software for quite a while. For NGS sites,
> I suspect they advertise an incomplete path.
>
> Cheers,
> Oxana
>
>