[gin-data] Update Ftp transfers

[Aleksandr Konstantinov]

On Mon, 28 Aug 2006 16:05:45 -0500 (CDT)
Raj Kettimuthu <kettimut at mcs.anl.gov> wrote:

> success :)

Success (exit code 0) in most cases means failure for lseek() function, it
is supoosed to return location in file.

> 
> On Mon, 28 Aug 2006, Aleksandr Konstantinov wrote:
> 
> >
> > 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
> > > >
> > > >
> > >
> >
> >
> > --
> >
> >


--