[gin-data] Update Ftp transfers

[Aleksandr Konstantinov]

I wonder what would be result of seek() on /dev/null :)

A.K.


On Thu, 24 Aug 2006 00:45:41 -0500 (CDT)
Raj Kettimuthu <kettimut at mcs.anl.gov> wrote:

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


--